home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0399 / 183 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. Date: Tue, 30 Mar 93 19:14:21 -0800
  2. From: ersmith@netcom.com (Eric R. Smith)
  3. Message-Id: <9303310314.AA23393@netcom.netcom.com>
  4. To: mint@atari.archive.umich.edu
  5. Subject: Re: shared libraries for MiNT
  6.  
  7. >I really think we need to have an object format that includes separate
  8. >segments for blockdata, blockbss, and maybe even blocktext for constant
  9. >arrays & structures. That's the only way to insure enough breathing space
  10. >while using 16 bit offsets.
  11.  
  12. Maybe so. (Text shouldn't be a problem, since I'm assuming that the text
  13. segment is constant, and since references to text don't need to be
  14. base register relative -- the library's text will appear in the "non virtual"
  15. part of every process' address space, i.e. at the same address in every
  16. process.) The advantage of DRI format is that most ST compilers can
  17. spit it out, but if we can come up with a better format and a conversion
  18. tool then we can go with the better format.
  19.   
  20. >Just a minor note, a5 is unusable for this purpose because it is zeroed
  21. >by Supexec. The current baserel stuff uses a4.
  22.  
  23. a5 is zeroed by Supexec in TOS, or in MiNT? If in MiNT, it's a bug, but
  24. in any case I guess we can stick with a4 for compatibility.
  25.   
  26. >  The data and bss segments of a given shared library will always be
  27. >  located at the same (relative) offset in the data/bss area of
  28. >  a program using that library. (Note that I'm going to call the
  29.  
  30. >I don't understand how this can be enforced without collisions. Is the load
  31. >address & size of the data section stored in the respective library? What
  32. >happens if the library is revised and the data section changes in size? Also,
  33. >it seems that trying to deal with gaps from unused libraries will be messy...
  34.  
  35. Sorry, I guess I didn't make that part clear in my post: the load address
  36. of the data section is determined by the kernel when the library is first
  37. loaded from disk. That is, the kernel goes through the list of currently
  38. loaded libraries, examines their current offsets, and figures out where to
  39. put the new library based on that. That scheme should work because a
  40. library must be loaded before it can be used (that's why the shared library
  41. info is prepended to executables linked with the shared libs; the kernel would
  42. have to load those libraries before it loads and relocates the executable,
  43. rather than having the executable do an exec of /bin/ld.so or whatever, as
  44. SunOS does).
  45.  
  46. >Finally, what about library code referencing data symbols that are external
  47. >to the library? (I think e.g. curses references some of termcap's variables...)
  48.  
  49. No problem, as long as there's only 1 data space that all libraries share;
  50. that's the advantage of using just 1 base register for all the libraries.
  51. The disadvantage, of course, is that with 16 bit offsets we run out of
  52. room relatively quickly. On 68020+ machines you can use 32 bit offsets
  53. directly; on 68000s you have to do register loading, which is a pain but
  54. I think is do-able. (I think the OS-9 port of gcc does this.)
  55.  
  56. >Is this scheme going to only support Atari-generated libraries, or will anyone
  57. >be able to write a shared library?
  58.   
  59. Since the data load address is determined at library load time, anyone
  60. can write a shared library -- there won't be any "master list" of
  61. load addresses to update.
  62.  
  63. >  Another disadvantage is that program load times will be longer, since
  64. >  the kernel is going to have to do the relocation and symbol resolving.
  65.  
  66. >Meaning that executables must never be stripped, as well, right? And, just
  67. >to clarify, this is not an attempt at providing dynamic loading and linking
  68. >as well, is it? (Oh, I see, you can strip any resolved symbols, of course,
  69. >and only leave the unresolved ones in a program file...)
  70.   
  71. Right, unresolved symbols would have to be left in the binary somehow.
  72. Actually, I guess we could remove even those, if we used a different
  73. object file format that had multiple relocation tables; then the symbols
  74. could be resolved by the linker to something like "12 bytes from the
  75. start of library A's data space" or "20 bytes from the start of the
  76. program data space". That would make things easier for the kernel, at the
  77. cost of leaving the "holes" caused by unused libraries (e.g. if there
  78. are currently 4 libraries loaded, A through D, and a program used only
  79. library D, then the data space that A-C would occupy would have to be
  80. left unused in the program image.)
  81.  
  82.  
  83.